1. Field of the Invention
The present invention relates to storage area networks, and more particularly, to an apparatus and method for a Generic Service locking mechanism that enables a Host to lock the Fibre Channel Switching Fabric of a storage area network so that the Host may implement changes across the Switching Fabric.
2. Background of the Invention
With the increasing popularity of Internet commerce and network centric computing, businesses and other organizations are becoming more and more reliant on information. To handle all of this data, storage area networks or SANs have become very popular. A SAN typically includes a number of storage devices, a plurality of Hosts, and a number of Switches arranged in a Switching Fabric that connects the storage devices and the Hosts.
Most SANs rely on the Fibre Channel protocol for communication within the Fabric. For a detailed explanation of the Fibre Channel protocol and Fibre Channel Switching Fabrics and Services, see the Fibre Channel Framing and Signaling Standard, Rev 1.70, American National Standard of Accredited Standards Committee (NCITS), Feb. 8, 2002, and the Fibre Channel Switch Fabric—2, Rev. 5.4, NCITS, Jun. 26, 2001, and the Fibre Channel Generic Services—3, Rev. 7.01, NCITS, Nov. 28, 2000, all incorporated by reference herein for all purposes.
In Fibre Channel, each device (Hosts, storage devices and Switches) is identified by an unique eight (8) byte wide Node_Name assigned by the manufacturer. When the Fibre Channel devices are interconnected to form a SAN, the Node_Name (along with other parameters) is used to identify each device. Fibre Channel frames are used for communication among the devices in the SAN. The Node_Name, however, is not used by the frames. Instead the Fibre Channel Port of each end device (Hosts and storage devices) is addressed via a three (3) byte Fibre Channel address (or FC_ID), allocated dynamically to the end devices by the Fabric.
Fibre Channel based SANs are often organized into zones. Within each zone, Hosts can see and access only storage devices or other Hosts belonging to that zone. This allows the coexistence on the same SAN of different computing environments. For example, it is possible to define on a SAN a Unix zone and a separate Windows zone. Unix servers belonging to the Unix zone may access only storage or Hosts devices within the Unix zone, and do not interfere with the other devices connected to the SAN. In the same manner, Windows servers belonging to the Windows zone may access storage or Hosts devices only within the Windows zone, without interfering with the other devices connected to the SAN. The SAN administrator may define in a SAN multiple zones, as required or dictated by the computing and storage resources connected to it. The Switching Fabric allows communications only between devices belonging to the same zone, preventing a device of one zone from seeing or accessing a device of another zone.
Zone administration is a significant aspect of maintaining a complex SAN. Whenever the needs of the SAN change, the administrator has to modify or redefine the zone structure enforced by the Fabric. For example, this may happen when a device is added to the SAN or removed from it, or when a specific device, such as a tape drive, has to be accessed by different Hosts at different times. Typically, the administrator accomplishes the administration task using a management application running over one of the Hosts connected to the SAN. The management application sends requests to a generic function provided by the Fibre Channel Fabric called “Management Service”, which enables the management of the entire Fabric.
The standard that provides the framework for this logical interaction between a Host and the entire Fabric is FC-GS-3. This standard defines a protocol, called the Common Transport (CT), required to exchange information between a Host and the various logical functions provided by the Fabric. Each logical function is called a Generic Service (GS) and is identified by using a “well known” Fibre Channel address in the Fibre Channel frames. As an example, if a Host transmits Fibre Channel frames with a destination address equal to hex‘FFFFFA’ or hex‘FFFFFC’, these frames will be delivered respectively to the Management Service or to the Directory Service functions of the Fabric. These Services may respond to the Host according to the requests that they received.
Typically, the FC-GS-3 protocols and functions are implemented in software running on the Hosts and corresponding software running on the various Switches of the Fabric. Within each GS Service, there may be various server subtypes. As an example, within the Directory Service there are two standard server subtypes: the Name Server, used to resolve FC Names in FC addresses, and the IP Address Server, used to resolve IP addresses (used by the Internet Protocol packets) into FC Names or addresses. Of interest, within the Management Service, there are server subtypes associated with Fabric management (the Fabric Configuration Server) and with zones management (the Fabric Zone Server). A specific field in the CT protocol uniquely identifies to which subserver is directed a FC frame addressed to a certain Service. Thus, the SAN administrator is able to manage and configure zones in the Fabric through a Common Transport communication between the management application and the Fabric Zone Server. FC-GS-3 defines a set of CT requests to define, modify, remove, or enforce zones.
Inside the Fabric, each Switch has to process the zone configuration data to enforce the rules that make sure that Hosts and storage devices in a zone can see and access only the Hosts and disks in that zone. To accomplish this, each Switch in the Fabric maintains a zone database that lists which Hosts can access which storage devices in the Fabric. The Switch-to-Switch interactions required to ensure that each Switch has a consistent version of this information are defined in the FC-SW-2 standard.
To update or change a zone configuration within a Fabric, FC-SW-2 defines the Zone Change Protocol. With this protocol, the Switch that wishes to propagate its zoning configuration over the other Switches of the Fabric is called the “managing Switch”, while the others are called “managed Switches”. Typically, the managing Switch is the Switch that received an updated zoning configuration from a management application via the GS mechanism described above. The Zone Change Protocol implements a four step process to distribute a zone change across the Switching Fabric. In general terms, the managing Switch locks the other Switches of the Fabric (step 1); propagates the changes across the Fabric to the other Switches (step 2); commits those changes (step 3); and then releases the lock on the Fabric (step 4).
Specifically the zone change protocol defines four class F frame sequences: Acquire Change Authorization (ACA); Stage Fabric Configuration (SFC); Update Fabric Configuration (UFC); and Release Change Authorization (RCA). The Switch that is trying to act as the managing Switch begins the protocol by sending an ACA sequence to all the other Switches in the Fabric. If one or more Switches reject the ACA request, then there is another Switch in the Fabric that is trying to lock the Fabric at the same time. In this situation, the protocol is aborted and the Switches that tried to become the managing Switch release the lock on the Switches that accepted their ACA request by sending them an RCA sequence. On the other hand, if all the Switches accept the request, then the Switch that initiated the process locks the Fabric and becomes the managing Switch. At this point, the managing Switch sends to each managed Switch an SFC sequence, containing the new zoning configuration. Each managed Switch checks its zone database to determine if the new zoning configuration can be supported. If a managed Switch can not support the change, a reject message is sent to the managing Switch and the zone change protocol is aborted by the managing Switch by sending an RCA to the managed Switches. If on the other hand the new zoning configuration can be supported, an accept is sent by all of the managed Switches to the managing Switch. In this case, the managing Switch asks the managed Switches to implement the new zoning configuration, by sending to each of them the UFC sequence. On receiving the UFC sequence, the managed Switches implement the requested change and update their zone databases respectively. The managed Switches then send out an accept when the update is completed. When the managing Switch receives all the accepts, then it releases the lock on the Fabric by sending to the managed Switches the RCA sequence. The Fabric is considered no longer locked when all the accepts of the RCAs has been collected by the managing Switch. In this manner, zone changes across the Fabric of a Fibre Channel based SAN can be made.
Several mechanisms are missing from the FC-GS-3 and FC-SW-2 standards. In particular no specification exists to relate the management actions performed by an administrator through the FC-GS-3 services with the Switch-to-Switch interactions defined in FC-SW-2. Further FC-GS-3 does not define today any mechanism to lock a Service, enabling the serialization of the management access to that Service. Thus, two administrators running two management applications connected to two different Switches of the same Fabric may manage the Fabric at the same time, often resulting in unpredictable results. Furthermore, FC-GS-3 defines other Services different from zoning which suffer from the same problem, the lack of a generic locking mechanism at the Service level. Since these services are based on a database replicated over all the Switches of the Fabric, it is difficult to manage the consistency of the various database copies and to implement the service across the Fabric without a locking mechanism.
An apparatus and method for a Generic Service locking mechanism for a Fibre Channel Switching Fabric of a storage area network is therefore needed.